How the X-Ref subsystems work

This section uses two tables to describe how the X-Ref subsystems used by SNiFF+ work.
RAM-based and DB-driven cross reference management is contrasted, first in the context of C/C++, then of Java/all other non-C/C++ languages, respectively.
Note that the tables do not describe user interaction, each column simply outlines what SNiFF+ does at each stage. Each table is followed by a summary of the immediate implications.
RAM-based versus DB-driven cross referencing in C/C++
The following table is divided into three rows, each representing a stage in the cross reference management cycle. These stages are

- Parsing
How parsing is triggered is described under Extracting symbol information. The table includes only X-Ref related information.
- Generating
While the first step in the X-Ref process takes place during parsing, the following steps can be triggered either on demand immediately after project setup, or using the menu command: Project > Update Cross Ref Info. If the procedure is not invoked by the user, it is automatically started when the first Referred-By query is issued after a (re-)parse.
- Querying
Note that, if source files have been modified, or if structural changes have been made to projects, both the "Generating" and "Querying" stages are triggered to incrementally update X-Ref information when you issue your first subsequent Referred-By query.

Stage | RAM-Based | DB-Driven
Parsing | Generate temporary lexical analysis files ( *.lex files), one for each source file parsed. These files contain fuzzy descriptions of what is referenced where, and are saved to disk to be used as input for later generation of cross reference information.

- Same as RAM-based.

Generating

- Interpret the

lex files in the context of the symbol table.
- Resolve the fuzzy descriptions in
lex files and write information to actual cross reference files ( *.ref files); these are needed for Referred-By queries.
- Create/update indexes (
*.index files). A global index is written per project.
- Save
ref and index files to disk.
- Delete
lex files.

- Interpret the

lex files in the context of the symbol table.
- Resolve the fuzzy descriptions in
lex files in memory.
- Interpret and save resolved X-Ref information to database.
- Delete
lex files.
Querying

- First query after file/project modifications: apply "Generating" stage (above) to increment.
- Load index and necessary

ref files to memory.
- Resolve query and display results.

- First query after file/project modifications: apply "Generating" stage (above) to increment.
- Query database and display results.

Summary

- For C/C++ files, there is no difference in the parsing stage.
Differences are language-specific -- compare following table.
- During the generation stage, procedures differ.
Under the RAM-based system,

ref files are written to disk and indexes have to be created and written to disk.
Under the DB-driven system, no ref or index files need be written to disk, but the lex file information needs to be interpreted so that the database can handle it, and then this has to be written to the database.
Result: When all the X-Ref information has to be generated for large software systems (project setup / forced reparse), the generation time is noticeably longer under the DB- driven system. For incremental updates (after file/project modifications, regular/nightly updates), the generation time differences will generally be negligible.
- Major differences are apparent at the querying stage.
Under the RAM-based system, the index(es) and all necessary ref files have to be loaded. Depending on the size of the project and nature of the query (and the what is queried in which order), this can be time and memory consuming.
Under the DB-driven system, the database is directly queried, resulting in constantly fast queries and negligible additional resource consumption -- regardless of how complex the query. The first Referred-By query after file/project modifications takes longer under both technologies because incremental differences have to be processed before queries are resolved.
RAM-based versus DB-driven cross referencing in Java
The following table is divided into two rows, each representing a stage in the cross reference cycle. These stages are

- Parsing and Generating
How parsing is triggered is described under Extracting symbol information. The table includes only X-Ref related information. For Java and other non-C/C++ languages, all X- Ref information is generated during parsing. This means that, to force an update of X-Ref information, you need to use the Force Reparse menu command (the Update Cross Reference Info command has no effect in non-C/C++ languages).
- Querying
By the time a query is issued, all X-Ref information has already been generated.

Stage | RAM-Based | DB-Driven
Parsing and Generating | Generate cross reference files ( *.ref files). Create/update ref file indexes ( *.index files). A global index is written per project. Save ref and index files to disk.

- Interpret X-Ref information in memory.
- Write X-Ref information directly to database.

Querying

- Load index(es) and necessary

ref files to memory.
- Resolve query and display results.

- Query database and display results.

Summary

- Under the RAM-based system,

ref files are written to disk and indexes have to be created and written to disk during Parsing.
Under the DB-driven system, no ref or index files need be written to disk, but the X- Ref information extracted by the parser has to be interpreted so that the database can handle it, and then the information has to be written to the database.
Result: When all the X-Ref information has to be generated for large software systems (project setup / forced reparse), the generation time is noticeably longer under the DB- driven system. For incremental updates (after file/project modifications, regular/nightly updates), the generation time differences will generally be negligible.
- Major differences are apparent in the querying stage.
Under the RAM-based system, the index(es) and all necessary ref files have to be loaded. Depending on the size of the project and nature of the query (and the what is queried in which order), this can be time and memory consuming.
Under the DB-driven system, the database is directly queried, resulting in constantly fast queries and negligible additional resource consumption -- regardless of how complex the query.